Today's video streaming technologies are almost exclusively based on the HTTP (“HyperText Transfer Protocol”, RFC 2616) protocol and designed to work efficiently over large and distributed HTTP networks such as the Internet. HTTP-based streaming technologies are very convenient, as HTTP allows going through firewalls and guarantees data integrity by relying on TCP (“Transmission Control Protocol”, RFC 793).
Adaptive BitRate (ABR) is one popular HTTP based streaming technique used in streaming contents over computer networks. HLS (“HTTP Live Streaming”), which is a video streaming communications protocol based on HTTP and developed by Apple Inc., is one particular implementation of ABR. HLS works by breaking an overall AV (“Audio/Video”) content into a sequence of small HTTP-based file downloads. Each file contains one chunk of an overall potentially unbounded transport stream. The AV content is thus divided into chunks, wherein a chunk is a portion of the AV content.
As the AV content is played, a client device decoding the AV content may select from a plurality of different alternate versions (or layers) containing the same material encoded at various respective bitrates, a version adapted to available network resources and/or available processing resources of the client device. At the start of the streaming session, the client device downloads a playlist in the form of a text file (or manifest file) with an M3U, m3u8, ISM, ISML, or MPD file extension. This manifest file contains metadata describing the plurality of versions.
A similar ABR approach is implemented by Smooth Streaming, which is a feature of Internet Information Services (IIS) Media Services, an integrated HTTP-based media delivery platform provided by Microsoft Corp. Contrary to HLS wherein the AV stream is truncated in plural files containing chunks complemented with playlist files, Smooth Streaming relies on a single AV stream truncated into pieces, each piece of stream containing a descriptor indicating the concerned layer and a reference time in the AV stream.
One may similarly consider Adobe Systems' HTTP Dynamic Streaming (HDS) and Dynamic Adaptive Streaming over HTTP, a multimedia streaming technology developed by the Moving Picture Experts Group (MPEG), and referred to as MPEG DASH.
While ABR works very well over the Open Internet on any type of device, the connected nature of the HTTP protocol over a non-managed network creates some Quality of Experience (QoE) issues for users of OTT (Over-the Top) video service. This is mainly due to the fact that OTT service platforms rely on one single Content Delivery Network (CDN) platform (called just “CDN” in the following) to deliver an HTTP AV content. As a reminder, a CDN is constituted of computers interconnected by the Internet and cooperating to deliver contents to users. More precisely, a CDN is constituted of original servers from which contents are injected in the CDN for replication, peripheral servers geographically spread over the network in which the contents of the original servers are replicated, and routing mechanisms allowing a user request for a content to be computed by the closest server. It is known however that relying on one CDN may create some issues such as scalability issues due to high numbers of users, variable performance depending on the user position with respect to the CDN, etc. Using one CDN may create additional issues. For instance, said CDN could stop or the connection to said CDN could be overloaded.
To overcome these issues, multi-CDN approaches have been developed. A multi-CDN approach basically consists in requesting chunks of a same audio/video content to a plurality of CDN. These approaches have at least the advantage of increasing in average the bitrate delivered to the client devices. However, these approaches are known to create some burstiness in the reception of data by AV players in charge of displaying the AV content in the client devices. In other words, data are received in bursts (periods of high bitrate followed by period of low bitrate) instead of being received with a bitrate varying slowly.
ABR AV players implement generally a strategy to maximize the user QoE by assessing different parameters including CPU usage in the client device, screen size, codecs, frame rate or network conditions. Assessing network conditions consists in measuring the bitrate of incoming data in order to select the most adapted layer of the requested AV content that will maximize the AV bitrate (hence the quality) while maintaining a continuous playing of the AV content.
Burstiness may lead to a frequent overestimation or underestimation of the real network conditions. An overestimation results in draining video buffers which may lead to a video stop until buffers are refilled. An underestimation results in playing a suboptimal video profile compared to what could be really achieved. Moreover, frequent over and underestimations lead to a frequent change of the requested layer, and consequently to a bad experience for the user, since the quality of the content it is watching is frequently changing.
FIG. 9 illustrates an example of estimation of network conditions. FIG. 9 represents the reception bitrate received by an AV player in function of the time, the AV video player receiving data from a plurality of CDN. Successive chunks are requested to the plurality of CDN. For instance, if the plurality comprises three CDN, named CDN1, CDN2, CDN3, the AV player requests chunk “1” to CDN1, chunk “2” CDN 2 and chunk “3” to CDN 3. When the bitrate of each CDN is the same, the AV player receives nearly a constant bitrate. In that case, there is no problem to estimate a bitrate representative of the real reception bitrate of the AV player. But, problems occur when one CDN has a lower bitrate than others.
In the example of FIG. 9, we suppose that the AV player estimates periodically its reception bitrate. In FIG. 9, items 901 to 908 represent periods of estimation of the reception bitrate by the AV player. In FIG. 9, from time T0 to time T1, we have represented a bitrate corresponding to a reception bitrate of a first chunk transmitted by CDN1. From time T1 to time T2, we have represented a bitrate corresponding to a reception bitrate of a second chunk transmitted by CDN 2. From time T2 to time T3, we have represented a bitrate corresponding to a reception bitrate of a third chunk transmitted by CDN 3. During period of estimation 901, the AV player estimates a high bitrate. Since high bitrate has been measured, the AV player decides to request a high profile. But then during period of estimation 902, the reception bitrate decreases and the AV player estimates an average bitrate. Since average bitrate has been measured, the AV player decides to request an average profile. During period of estimation 903, the reception bitrate remains low. Since low bitrate has been measured, the AV player decides to request a low profile. During period of estimation 904, the reception bitrate increases. In reaction to that increase, the AV player requests again an average profile. As can be seen, the AV player is frequently changing the profile it is requesting which is not acceptable for a user. The estimation of the reception bitrate would be more efficient if the AV player has had averaged to bitrates at least from time T0 to time T3. Indeed, in that case, the AV player would average the reception bitrate during this period, which would be more representative of the actual reception bitrate and would prevent the frequent change of the requested profiles.
It is desirable to overcome the above drawbacks of the prior art. It is desirable to provide a method and a device allowing an AV player benefiting of a multi-CDN approach without perturbing the behavior of the AV player and more particularly, preventing the AV player frequently over or underestimating the bitrate available on the network. More globally, it is desirable to provide a method allowing improving the QoE perceived by a user in the context of a multi-connections approach (i.e. Multi-CDN and/or CDN providing multiple connections).